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A METHOD OF PROCESSING DATA FOR A SYSTEM MODEL 
FIELD OF THE INVENTION 
[0001] The present invention relates to the modeling of data using data processors 

such as computers. ' \ 

5 [0002] In its preferred form the present invention relates to spreadsheet modeling. 

For convenience the invention wilPbe described with reference to spreadsheet modeling but 
should be understood as having wider applications such as other modeling applications. 
[0003] In the field of financial analysis computer models were originally developed to 

make it relatively quick and easy to examine many different scenarios and to calculate more 
10 complex indicators such as net present values. To assist in this regard several computer 
modeling systems were developed in languages such as FORTRAN to facilitate the 
construction of computer models, 

[0004] Computer modeling systems had several attractive features including the 

ability to handle very complex calculations such as complex depreciation regimes and the 

15 maintenance of asset registers involving both depreciation and revaluation. Furthermore 
batch operation allowed several complex scenarios and sensitivities to be built and stored 
then run quickly when required. In addition computer modeling systems provided an ability 
to switch amongst alternatives or optional scenarios using available options. 
[0005] However computer modeling systems suffered from significant problems 

20 including the high level of programming expertise required, especially if the logic of the 
model needed to be changed. In addition they were invariably inflexible, because decisions 
needed to be made in advance regarding the order in which calculations were to be 
performed. Furthermore, because calculations were carried out in computer code hidden 
from view third party users often regarded the systems as black boxes and had little 

2 5 confidence in the output. 

[0006] As an alternative to computer modeling systems spreadsheet systems were 

developed which had the advantage of requiring little programming expertise and provided 
more intuitive methods for inputting data, for specifying formulae and for displaying results. 
[0007] The spreadsheet system typically attempts to devise a schedule of calculations 

30 so that each cell value is calculated before the cell is itself required to be used in the 
calculation of cells which depend on it. 

[0008] If such a schedule can be created the spreadsheet system calculates the cells. 

[0009] Spreadsheet systems also have some drawbacks however. These include 

auditing problems associated with complex calculations where cell formula are cumbersome 
35 and difficult. In addition spreadsheet systems are typically poorly equipped for batch 
processing of complex and/or inter-related scenarios. Furthermore they have limited 
capability to switch amongst alternative or optional scenarios using options. Finally the lack 




of an interface for reading large amounts of input data can make data entry time consuming 
and prone to error, 

[0010] Because of the above defects with spreadsheet modeling, modelers have 

tended to use two methods for creating complex spreadsheet models. These include 
5 comprehensive models involving the*creation of a comprehensive spreadsheet containing all 
reasonably conceivable calculations that might be encountered in the particular field. This 
has the disadvantage of large storage and execution time overheads and the provision of 
features which are rarely if ever used. 

[0011] Alternatively a standard model may be modified to handle calculations 

10 specific to the problem at hand. This naturally has the associated disadvantage of requiring 

considerable time and effort from the user in rewriting. This technique is also prone to errors. 

BACKGROUND OF THE INVENTION 

[0012] The present invention relates to a method of processing data which can be 

incorporated into spreadsheet modeling systems. In its preferred form the method can be 
15 incorporated in a hybrid spreadsheet modeling system incorporating the best features of 

computer modeling systems and spreadsheet systems. 

[0013] According to one aspect of the present invention there is provided a method 

for processing data for a system model including the steps of providing a model specification 
having a plurality of types of items including at least one first item type wherein associated 

20 data is obtained from data input into the system and at least one second item type wherein 
associated data is obtained from an operation performed on the data associated with at least 
one item stored in a first database, inputting data into the system, searching the input data for 
first item types, storing data associated with first item types in the first database, reading the 
or one of the second item types in a determining step including determining whether the first 

25 database includes the or each prerequisite item necessary to determine the one second item 
type by obtaining associated data from an operation performed on data associated with at 
least one item stored in the first data base, storing the one second item type in the first 
database if the or each prerequisite item is present, successively reading each other second 
item type and storing it in the first database if the or each prerequisite item is present in the 

30 first database and outputting an indication that the system model can be produced if items of 
the model specification are stored into the first database. 

[0014] Preferably each second item type (item of the second type) is read 

successively. 

[0015] It is preferred that the method includes at least two items of the second type. 

35 

[0016] It is preferred that items include parameters or variables such as Revenue or 

Outlay in a financial model. 



[0017] Associated data may include any type of data such as the name of items or 

quantities associated with the items. 

[0018] According to one embodiment an item may include a group of parameters and 

their associated names. 

5 [0019] It is preferred that the method incorporates an iterative process of reading 

second item types whenever a second item type is stored in the first database. 
[0020] The first database should be understood as including any memory storage area 

with or without divisions into separate areas or separate databases. 

[0021] Preferably the method includes storing first item types in modules within the 

10 first database. 

[0022] Preferably each module is configured to perform operations on data associated 

with first item types (items of the first type) having at least one similar characteristic which 
are stored in the same module. 

[0023] It is preferred that the method includes a sorting procedure as items and 

15 associated data are stored in the first database. 

[0024] It is preferred that the system produces an output indication if predetermined 

items are stored in the first database. 

[0025] It is preferred that the method includes nesting modules within other modules. 

[0026] Preferably the method includes the step of determining whether a second item 

20 type can be stored in the first database by associating the second item type with an item 
determinant which specifies the or each prerequisite item for evaluation of the second item 
type. 

[0027] Preferably the method includes a determinant step of searching the first 

database for the or each prerequisite item of the second item type. 
25 [0028] The determining step is preferably interpreted in a broad sense to mean any 

operation, evaluation or process of arriving at an outcome. 

[0029] The determinant and/or determining step may include a Boolean operation 

which produces a true or false result depending upon whether the or each prerequisite item is 
located in the first database. 
30 [0030] The first database may include one or more separate storage areas. 

[0031] Preferably the result is true if prerequisite items are located in the first 

database. 

[0032] The first item types may correspond to input items. 

[0033] The second item types preferably have corresponding item determinants. 

35 [0034] Preferably the second item types are non-input items. 

[0035] The method may include the step of adding a second item type to the first 

database if the associated item determinant evaluates to true. 
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[0036] The method may include the step of providing a consolidated storage area for 

storing items and for evaluating item determinants. 

[0037] Preferably the method includes the step of evaluating the item determinant for 

each second item not stored in the first database. 
5 [0038] The method may include the step of storing in the first database each second 

item type for which the item determinant is true. 

[0039] The method preferably includes the step of storing second item types in a 

second database if their associated prerequisite items are not located in the first database. 
[0040] Preferably the method includes repeating the evaluating step for any second 

1 0 item type in the second database. 

[0041] Preferably the method includes repeating the storage step for each second item 

type stored in the second database. 

[0042] It is preferred that the evaluating and storing steps are repeated until the 

storage step results in no additional second item types being added to the first database. 
15 [0043] 'Alternatively the method includes repeating the evaluating and storing steps 

until all evaluated item determinants are false. 

[0044] It is preferred that the second database comprises a consolidated instance 

array. 

[0045] The method may include the step of adding second items for which the item 

2 0 instances evaluate to false to the second database. 

[0046] It is preferred that any second item type added to the first database after the 

evaluating step is performed on the second database results in the removal of that second item 
from the second database. 

[0047] It is preferred that the evaluation step is repeated on second item types 

2 5 remaining in the second database if the second item type is transferred to the first database. 

[0048] The method may include the step of storing formula for second item types in a 

formula database. 

[0049] The method may include evaluating each first and/or second item type stored 

in the first database in accordance with the associated formula stored in the formula database. 
30 [0050] The method preferably relates to a spreadsheet model. 

[0051] The method may include allocating rows or columns for each item in the first 

database. 

[0052] The method may include the step of writing into the cells of the rows and 

columns the necessary formula from the formula database. 

3 5 [0053] It is preferred that the method includes the step of writing into the cells of the 

rows and columns any other information including formatting requirements of the cells. 
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[0054] Alternatively the method includes the step of identifying first item types 

required for each second item type. 

[0055] Preferably the method includes associating with each second item type all first 

item types and/or second item types required before the second item type can be evaluated. 
5 [0056] The method may include storing second item types and associated first item 

types and/or second item types. 

[0057] Preferably the method includes searching the first database for each second 

item type for an occurrence of each associated first item type and/or each second item type 
and storing the second item in the first database. 
10 [0058] According to another aspect of the present invention there is provided a 

computer program for implementing the method for processing data for a system model in 
accordance with any one of the preferred features. 

[0059] According to one aspect of the present invention the method is implemented 

by providing a model specification which is hard coded into the computer program which 
15 implements the invention. 

[0060] The method may include incorporating a model specification with a plurality 

of preconfigured options which can be individually selected as the model specification. 
[0061] According to one embodiment, the model specification is input into the system 

as a separate step. 

20 [0062] According to an alternative embodiment the model specification is selected 

from a model specification database containing a plurality of optional model specifications. 
[0063] According to another embodiment of the invention it is preferred that the 

model specification includes a plurality of operations associated with each second item type. 
Preferably the method includes selecting a model specification from the model specification 

2 5 database. 

[0064] Alternatively, the method includes the step of inputting a desired model 

specification. 

[0065] According to one embodiment, data associated with the second item type is 

derived from operations performed on data associated with prerequisite items for the second 
30 item type. 

[0066] According to another embodiment of the invention the method includes items 

of other types. 

[0067] Preferably data associated with an item of the second type can be determined 

directly from operations involving associated data rather than the items associated with that 
35 data. 

[0068] According to another embodiment prerequisite items may include items of the 

first and/or second type. 
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[0069] According to another aspect of the present invention there is provided a 

storage medium for storing a computer program described above. 

[0070] The words "comprising, having, including" should be interpreted in an 

inclusive sense, meaning that additional features may also be added. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0071] A preferred embodiment of the present invention will now be described by 

way of example only with reference to the accompanying drawings in which: 

Figure 1 shows a schematic representation of a model specification; 

Figure 2 shows a schematic representation of model input data; and 

Figure 3 shows a flow diagram of a method of processing data in accordance 
with the preferred embodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 
[0072] In accordance with the preferred embodiment a spreadsheet model is produced 

by combining model input data for a particular model with a model specification. 
[0073] The model builder uses the model specification to process the model input data 

to ultimately produce the spreadsheet model. 
[0074] The process involves three main tasks: 

identifying the items which must be created for a particular spreadsheet model; 

allocating rows or columns for these items; and writing into the cells of 
those rows and columns the necessary formula or other information and formatting the cells. 
[0075] The following description of the preferred embodiment incorporates the use of 

specially defined terms. These terms include: 

item, item instance and item determinant. 
[0076] In a financial model a particular parameter is evaluated according to a given 

formula or relationship between given variables. Thus a calculation of cash flow would be 
dependent upon the difference between Revenue and expenses. The particular names given 
to the variables is not important but they must be given some identifier and in this example 
they are each referred to as items having particular item names. 

[0077] As shown in Table 1, items are not scalar quantities but rows which typically 

contain numbers or formulae and may have an associated name and label. Thus table 1 
shows a very basic spreadsheet model with the items Revenue, Expenses and Cash Flow with 
different occurrences of the items appearing in columns C to H. 
Table 1 : A three "item" model 

[0078] In each case there is only one instance of the items revenue, expenses and cash 

flow. Additional instances of each item might be referenced by terms such as Revenue 2, 
Expenses A, Cash Flow 2, Cash Flow A. Thus if the model included items Revenue 1 and 
Revenue 2, these would be considered different instances of the item revenue. 
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[0079] The Cash Flow is calculated by subtracting the Expenses in each column of 

row 4 from the Revenue in the corresponding column of row 2. 
5 [0080] Another feature of the above example is that the items Revenue and Expenses 

would typically be input items and thus model input data which would be input to a computer 
by data entry personnel. The Cash Flow item however is not input to the system but is 
calculated from the input items Revenue and Expenses. Thus Cash Flow is evaluated based 
on two input items each having one instance. 
10 [0081] From the above an instance can be defined as one or more lines which contain 

values copied from model input data and/or spreadsheet reference to model input data values, 
spreadsheet formula, labels and formatting information. 

[0082] An instance as described above is a "concrete" entity in that it is defined in 

terms of actual lines on an actual spreadsheet. However, before a spreadsheet model can be 
1 5 created it is necessary to perform operations with putative instances to determine the actual 
instances that will be required. 

[0083] The term "item instance" is introduced to refer to instances in the abstract. An 

item instance may be actual instances on an actual spreadsheet or it may be a putative 
instance on a putative spreadsheet. 
20 [0084] There are two possible ways of approaching the definition of "Item Instance". 

[0085] Firstly by working from the concrete to the abstract, starting with actual 

spreadsheets and from there defining "Instances", then "Items" as a class of actual or putative 
"Instance", and finally "Item Instance" as an actual or putative instance of an Item. 
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[0086] Secondly working from the abstract to the concrete, defining an "Item" as a 

class of variables (each Item defined by an unambiguous identifier, such as "REV") which 
might exist in a Model built fi-om a Model Specification. An Item Instance can then be 
defined as an instance of the Item class. 

[0087] With these definitions we may proceed to consider the first of three main 

tasks: determining which Item Instances should exist in a particular model built fi-om a Model 
Specification and a set of Model Input Data. 

[0088] In the simplest method of the invention an Item Instance can be brought into 

existence as follows: 

if the Model Input Data contains input data for the Item Instance; and/or 

if the Item Instance is generated "internally" by the preferred method of the 

Invention. This process is described below. 

[0089] In the method of the Invention, each Item must be associated with 

"Determination Information" which can be used to determine which Item Instances should 
exist. The Determination Information must comprise at least one of (a) or (b): 
a) either: 

(i) a designation that instances of the Item may be associated with 
Instance Data; or 

(ii) a Spreadsheet Modeling Language convention that allows instances of 
the Item to be associated with Instance Data. A Spreadsheet Modeling 
Language convention may allow for instances of an Item to be 
associated with Instance Data by default (i.e. instances of an Item may 
be associated with Instance Data unless expressly designated 
otherwise). 

Items which may have instances associated with Instance Data are 
referred to as "Input Items"; and/or 
(b) a logical expression (an "Item Determinant") evaluated according to a 

set of rules such that it may be determined for which of all possible 
instances of the Item the expression is TRUE. 
Thus an Item Instance should exist if: 

the Item is an Input Item and the Item Instance has Instance Data included as 
part of Model Input Data; or 

the Item has an Item Determinant and the Item Determinant evaluates to 

TRUE for the Item Instance. 
[0090] To maintain the generality of the Invention, it is proposed that the rules for 

evaluating Item Determinants should not form part of the preferred method of the Invention 
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but should be implementation dependent. The rules used in the computer program 
embodying the Invention are set out in the examples which follow. 
Example 1 : Model Specification with Input Item and Item Determinant 



Commands and 
Item Names 


Label 


Item Type Specifier 
and Qualifier 








DC \/ 

Kb V 


Revenue 


T 
1 








EXP 


Expenses 


I 






-\ 


CASHFLOW 


Net cash flow 


ND(REV II EXP) 








DRATE 


Discount rate 


I 








NPV 


Net present value 


ND(CASHFLOW && DRATE) 



[0091] In this Model Specification: 

there are five Items: REV, EXP, CASHFLOW, DRATE and NPV; 

the Determination Information is as follows: 

Items REV, EXP and DRATE are Input Items as designated by the Item Type 
"I" but they have no Item Determinant. Therefore Instances of these Items can 
exist if and only if Instance Data has been provided for them; 
Item CASHFLOW is a non-input Item as designated by the Item Type "N" but 
it has an Item Determinant "(KEN \\ EXP)". The Item Determinant is 
evaluated according to the rule that it is TRUE if a corresponding Instance of 
either REV or EXP exists, and FALSE otherwise; and 

Item NPV is a non-input Item as designated by the Item Type "N" but it has an 
Item Determinant "(CASHFLOW Sl8l DRATEG)". The Item Determinant is 
evaluated according to the rule that it is TRUE if a corresponding Instance of 
CASHFLOW exists AND a corresponding Instance of DRATE exists. 
Otherwise it is FALSE. 

[0092] Note that according to this flow of logic, an Instance of NPV cannot exist 

unless there is a corresponding Instance of either REV or EXP. Yet, the Item Determinant for 
NPV contains no direct reference to either REV or EXP, 



[0093] The following is a sample of Model Input Data which could be used with this 

Model Specification. 
Example 2: Model Input Data 



REVl Steaming coal = 


7*50 


REV2 Rental income = 


7*10 




EXPl Steaming coal = 


7*25 


EXP3 Head Office = 4* 


■10 3*0 




DRATE2 Discount rate 


= 10% 



[0094] When combined with the Model Specification, this Model Input Data would 

cause the following spreadsheet Model to be created. 
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Example 3: Resultant Spreadsheet Model 
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Steaming coal 


Cell Contents 




CASHFLOW2 


Rental income 


Cell Contents 




CASHFLOWS 


Head Office 


Cell Contents 










Ei 


DRATE2 


Discount rate 


Cell Contents 












NPV2 


Net present value 


Cell Contents 











[0095] The Item Instances are determined as follows: 

Instances of REV, EXP and DRATE exist if they have Instance Data (REVl, 
REV2, EXPl, EXP3 and DRATE2); 

Instances of CASHFLOW exist if there is either a corresponding Instance of 
REV (CASHFLOWl and CASHFLOW2) or a corresponding Instance of EXP 
(CASHFLOWl and CASHFLOWS); and 

Instances of NPV exist if there is a corresponding Instance of CASHFLOW 

and a corresponding Instance of DRATE (NPV2). 
[0096] The preceding section describes which Item Instances should exist in a 

particular Model built from a particular set of Model Input Data, But it remains to be shown 
how this is actually achieved in a computer program. 
[0096] Referring to Figure 1 a model specification 10 is established having item 

names 11, item determinants and cell content information 13. A report array 14 contains 
formatting information 15 for each type of report 16. 

[0097] As shown in Figure 2, data which is input to the system is input as model input 

data 17 and is formatted with instance data including the name, instance ID and optional data. 
[0098] As shown in Figure 3 a modeling system for implementing a particular 

spreadsheet model consists of model input data 20, an item instance database 21, a model 
specification 22 and a consolidated instance array 23. 
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[0099] Processing of data occurs in accordance with the following four step 

procedure. 

[0100] Initially in step 1 as identified by item 24, the model input data 20 is scanned 

for instance data. In step 2 the database 21 is created to register all the item instances 
5 (identified by item name and instance identifier) for which there is instance data. 

In step 3, once all the item instances identified in model input data have been registered in the 
item instance database 21, each item in the model specification 22 is read and the item 
determinant (if any) of each item is evaluated and the item instance database 21 has added to 
it all item instances for which the item determinant evaluates to true according to the rules of 

10 evaluation. This processing step is identified in block 25 of Figure 3. 

[0101] The results of evaluating item determinants may change due to the registration 

of additional item instances to the item instance database 21. Thus in a fourth step, step 4, it 
is necessary to repeat the evaluation step of step 3 to ascertain whether an item determinant 
would now evaluate to true for an item instance for which it previously evaluated to false. 

15 [0102] For each item in each repetition of the evaluation step of step 3, the 

consolidated array 23 is estabHshed to store instance identifiers of the instances to be tested 
against an item determinant. Instance identifiers may be drawn from an operation on the item 
instances registered in the database 21 (for example the logical union of all instances of the 
item instances registered in the database) or from the application of a convention which 

20 identifies instances. The item determinant may be evaluated for each instance in the 
consolidated array 23. If it evaluates to true the item name and instance identifier are 
registered in the database 21. 

[0103] As part of the process of reading each of the items in the model specification, 

step 3 which incorporates processing blocks 25 and 26 is repeated in step 4 until no more 

2 5 item instances are added to the item instance database. This is referenced in processing block 
item 27. Thus the addition of item instances to the item instance database 21 may change the 
evaluation of item determinants in step 3, but if step 3 results in no additional item instances 
being registered in the database 21 then no matter how many additional repetitions occur of 
step 3 this will not change any item determinant from false to true. 

30 [0104] Applying these steps to Example 3, it will be seen that Item Instances REVl, 

REV2, EXPl, EXP3 and DRATE2 are registered in the Item Instance Database in Step 2 
because they have Instance Data. 

[0105] Instances of Item CASHFLOW are determined in Steps 3 and 4. In the current 

embodiment this is as follows: 
35 - all the Items referred to in the Item Determinant are identified. In Example I, 

the Items REV and EXP are identified; 
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a Consolidated Instance Array 23 is created containing the union of the 
Instance Identifiers of all the instances of the Items thus identified already 
registered in the Item Instance Database. In Example 1, this would contain the 
Instance Identifiers (derived from either REV and EXP), "2" (derived 
from REV) and "3" (derived from EXP). According to the rules of evaluation 
it is impossible for the Item Determinant to evaluate to TRUE for any other 
instance; 

the members of the Consolidated Instance Array 23 are examined in order: 
the Item Determinant evaluates to TRUE for Instance Identifier "1" because 
the corresponding Item Instance of REV (i.e. REVl) is already recorded in the 
Item Instance Database. It is not necessary to consider the existence of EXP 1; 
the Item Determinant evaluates to TRUE for Instance Identifier "2" because 
the corresponding Item Instance of REV (i.e. REV2) is already recorded in the 
Item Instance Database; and 

the Item Determinant evaluates to TRUE for Instance Identifier "3" because 
the corresponding Item Instance of EXP (i.e. EXP3) is already recorded in the 
Item Instance Database. 

[0106] The three Item Instances CASHFLOWl, CASHFLOW2 and CASHFLOW 3 

are therefore registered in the Item Instance Database; and 

[0107] In Step 4, this process is repeated. There are no more Item Instances of Item 

CASHFLOW added to the Item Instance Database in this step. 

[0108] The issue of whether the process can finish depends on whether instances of 

any item have been added in the most recent pass of step 3. 

[0109] It is possible for some instances of an item to be added in, say, the first pass of 

step 3, none added in the second pass, but more added in the third pass. However, if no 
instances of any item have been added then the model is complete. 

[0110] Instances of Item NPV are also determined in Steps 3 and 4. In the current 

embodiment this is as follows: 

all the Items referred to in the Item Determinant are identified. In Example 1 , 

the Items CASHFLOW and DRATE are identified; 

a Consolidated Instance Array is created containing the union of the Instance 
Identifiers of all the instances of the Items thus identified already registered in 
the Item Instance Database. Assuming that NPV is processed before 
CASHFLOW in the first pass of step 3, this would contain the Instance 
Identifiers "2" (derived from DRATE). No Instances of CASHFLOW exist at 
this stage; 

the members of the Consolidated Instance Array are examined in order: 
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the Item Determinant evaluates to FALSE for Instance Identifier "2" 
because the corresponding Item Instance of CASHFLOW (i.e. 
CASHFLOW2) is not registered in the Item Instance Database at this 
stage. 

5 No Instances of NPV are registered in the Item Instance Database at this stage; 

In Step 4, this process is repeated. By this time Item Instances CASHFLOW!, 
CASHFLOW2 and CASHFLOWS have been registered; 
a Consolidated Instance Array is registered containing the union of the 
Instance Identifiers of all the instances of the Items identified in the 
1 0 Determinant and already registered in the Item Instance Database. This would 

now contain the Instance Identifiers "1" (derived from CASHFLOW), "2" 
(derived from either CASHFLOW or DRATE) and "3" (derived from 
CASHFLOW); 

the members of the Consolidated Instance Array are examined in order: 
15 - the Item Determinant evaluates to FALSE for Instance Identifier "1" 

because the corresponding Item Instance of DRATE (i.e. DRATE 1) is 
not registered in the Item Instance Database; 

the Item Determinant evaluates to TRUE for Instance Identifier "2" 
because the corresponding Item Instances of both CASHFLOW (i.e. 
20 CASHFLOW2) and DRATE (i.e. DRATE2) are already registered in 

the Item Instance Database; and 

the Item Determinant evaluates to FALSE for Instance Identifier "3" 
because the corresponding Item Instance of DRATE (i.e. DRATE3) is 
not registered in the Item Instance Database; 
2 5 Only the Item Instance NP V2 is registered in the 

Item Instance Database; and 

the process is repeated again. As there are no 

more Item Instances added to the Item Instance Database in this step, the 
process can finish. 

30 It is possible in principle that an Item Instance could be added in Step 3 or on one of the 
repetitions of Step 3 and that in a later repetition of Step 3 the Item Determinant will evaluate 
to FALSE for that Item Instance (perhaps because other Item Instances have been added). A 
particularly problematic example of this is shown below. (The symbol "!" stands for the 
logical operator "NOT".) 

35 



14 



Example 4: Contradictory Item Determinants 



Commands and 
Item Names 


Label 


Item Type Specifier 
and Qualifier 








Item A 




ND(ItemC && ! ItemB) 








ItemB 




ND(ItemC && ItemA) 








ItemC 




I 



In Example 4, if an instance of Item C has been created from Instance Data then the 
5 corresponding instance of Item A should exist if and only if the corresponding instance of 
Item B does not exist. But the corresponding instance of Item B should exist if and only if 
the corresponding instance of Item A exists. This is a logical contradiction which cannot be 
eliminated. 

[0111] The method of the Invention handles this by adding Item Instances to the Item 

10 Instance Database but not deleting them. It is therefore possible that the final version of a 

Model might contain some redundant Item Instances. With good model specification this 

should not happen and, if necessary, redundant Instances can be "neutralised" using cell 

content information. 

Allocating rows or columns 
15 [0112] Once the Item Instances necessary for a Model have been determined, it is 

possible to allocate rows or columns to the Instances. 

[0113] It is proposed that the method of allocating rows and columns be 

implementation dependent so as not to limit the generality of the Invention. In particular: 

it is not essential for all rows or columns to be on a single spreadsheet. The 
20 Spreadsheet Modeling Language might contain methods of specifying that 

different Item Instances appear on different sheets, or that a Non-defining 

Occurrences of an Item Instance appear on different sheet from the Defining 

Occurrence; and 

it is not essential for a row or column to occupy the entire width or length of a 
25 spreadsheet. The term "Spreadsheet Fragment" is used to describe a single 

rectangular portion of a spreadsheet which is of sufficient size to 
accommodate a particular Model. This allows several (possibly interacting) 
Models to be built on a single spreadsheet. This does not prevent a 
Spreadsheet Fragment from being an entire spreadsheet, but it need not be. 
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[0114] In the examples it is assumed that a Model Specification is read sequentially. 

As each Item is encountered, a row or column is reserved for each Item Instance. Blank 
spaces or other formatting controls embedded in the Model Specification may be used to 
indicate empty lines, column headers, underlines, changes in number formats, or page breaks. 
[0115] The preferred embodiment has been described having regard to model 

specifications which are primarily externally sourced. However, the invention also includes 
model specifications which are hard coded into a computer program or computer. For 
example, a comprehensive model specification can be provided prior to use of the method. 
Binary data generated by the compiler could be removed and could be printed out as a set of 
integers. This could be hard coded into C++ source code in a software implementation as a 
constant integer array. The software program could then be distributed with a comprehensive 
model specification already hard coded into it. In such a situation any user of the method 
would be able to select a desired model specification from a multitude of different options 
which are hard coded into it. 

[0116] It is to be understood that, if any prior art publication is referred to herein, such 

reference does not constitute an admission that the publication forms a part of the common 
general knowledge in the art, in Australia or in any other country. 
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